[dpdk-dev] Building with 'make install T=' and 'make config T='

[dpdk-dev] Building with 'make install T=' and 'make config T='

[Wiles, Keith]

I am having a problem with ‘make install T=‘ command as I was using it before. I would normally build a x86_64-native-linuxapp-gcc, clang and icc or a different config all together. Currently the ‘make install T=‘ gives a warning message at the end of the build plus creates the x86_64-native-linuxapp-XXX directory. If I use the suggested ‘make config T=‘ command this command create a directory ‘build’ with a .config file. The problem is this method does not allow me to have multiple builds at the same time.

What is the suggested method to have multiple builds without installing  into the local file system?

Regards,
Keith

Re: [dpdk-dev] Building with 'make install T=' and 'make config T='

[Thomas Monjalon]

2015-12-09 14:39, Wiles, Keith:
> I am having a problem with ‘make install T=‘ command as I was using it before. I would normally build a x86_64-native-linuxapp-gcc, clang and icc or a different config all together. Currently the ‘make install T=‘ gives a warning message at the end of the build plus creates the x86_64-native-linuxapp-XXX directory. If I use the suggested ‘make config T=‘ command this command create a directory ‘build’ with a .config file. The problem is this method does not allow me to have multiple builds at the same time.
> 
> What is the suggested method to have multiple builds without installing  into the local file system?

The multiple build is not supported anymore. It was only building with
the default configuration.
If you want to test various builds, I suggest to use this script:
	scripts/test-build.sh
	http://dpdk.org/browse/dpdk/commit/?id=cd31ca579c

If you just want to compile, it is simple:
	make config T=x86_64-native-linuxapp-gcc O=my-gcc-build
	make O=my-gcc-build

Note: the documentation was updated when doing this change.
If you think something is missing, please comment.

Re: [dpdk-dev] Building with 'make install T=' and 'make config T='

[Wiles, Keith]

On 12/9/15, 8:59 AM, "Thomas Monjalon" <thomas.monjalon@6wind.com> wrote:

>2015-12-09 14:39, Wiles, Keith:
>> I am having a problem with ‘make install T=‘ command as I was using it before. I would normally build a x86_64-native-linuxapp-gcc, clang and icc or a different config all together. Currently the ‘make install T=‘ gives a warning message at the end of the build plus creates the x86_64-native-linuxapp-XXX directory. If I use the suggested ‘make config T=‘ command this command create a directory ‘build’ with a .config file. The problem is this method does not allow me to have multiple builds at the same time.
>> 
>> What is the suggested method to have multiple builds without installing  into the local file system?
>
>The multiple build is not supported anymore. It was only building with
>the default configuration.
>If you want to test various builds, I suggest to use this script:
>	scripts/test-build.sh
>	http://dpdk.org/browse/dpdk/commit/?id=cd31ca579c

Having a build script is great, but it give me an error on building. The script does not have a —help option and the unknown option is not very usefulas it does not explain the two option -jX and -s in that output message. I would have expected a bit more help instructions on using this command and adding a -h or —help would be useful. 

The error I get from the following command is: './scripts/test-build.sh x86_64-native-linuxapp-gcc’ building on a Ubuntu 15.10 with all patches. If I use ‘make install T=x86_64-native-linuxapp-gcc’ this command builds correctly with the warning at the end.

Custom configuration
Configuration done
Configuration done
Using local configuration
== Build lib
== Build lib/librte_compat
== Build lib/librte_eal
== Build lib/librte_net
  SYMLINK-FILE include/rte_compat.h
  SYMLINK-FILE include/rte_ip.h
  SYMLINK-FILE include/rte_tcp.h
  SYMLINK-FILE include/rte_udp.h
  SYMLINK-FILE include/rte_sctp.h
  SYMLINK-FILE include/rte_icmp.h
  SYMLINK-FILE include/rte_arp.h
== Build lib/librte_eal/common
  SYMLINK-FILE include/generic/rte_atomic.h
  SYMLINK-FILE include/generic/rte_byteorder.h
  SYMLINK-FILE include/generic/rte_cycles.h
  SYMLINK-FILE include/generic/rte_prefetch.h
  SYMLINK-FILE include/generic/rte_spinlock.h
  SYMLINK-FILE include/generic/rte_memcpy.h
  SYMLINK-FILE include/generic/rte_cpuflags.h
  SYMLINK-FILE include/generic/rte_rwlock.h
  SYMLINK-FILE include/rte_branch_prediction.h
  SYMLINK-FILE include/rte_common.h
  SYMLINK-FILE include/rte_debug.h
  SYMLINK-FILE include/rte_eal.h
  SYMLINK-FILE include/rte_errno.h
  SYMLINK-FILE include/rte_launch.h
  SYMLINK-FILE include/rte_lcore.h
  SYMLINK-FILE include/rte_log.h
  SYMLINK-FILE include/rte_memory.h
  SYMLINK-FILE include/rte_memzone.h
  SYMLINK-FILE include/rte_pci.h
  SYMLINK-FILE include/rte_pci_dev_ids.h
  SYMLINK-FILE include/rte_per_lcore.h
  SYMLINK-FILE include/rte_random.h
  SYMLINK-FILE include/rte_interrupts.h
  SYMLINK-FILE include/rte_alarm.h
  SYMLINK-FILE include/rte_string_fns.h
  SYMLINK-FILE include/rte_version.h
  SYMLINK-FILE include/rte_tailq.h
  SYMLINK-FILE include/rte_eal_memconfig.h
  SYMLINK-FILE include/rte_malloc_heap.h
  SYMLINK-FILE include/rte_hexdump.h
  SYMLINK-FILE include/rte_devargs.h
  SYMLINK-FILE include/rte_dev.h
  SYMLINK-FILE include/rte_pci_dev_feature_defs.h
  SYMLINK-FILE include/rte_pci_dev_features.h
  SYMLINK-FILE include/rte_malloc.h
  SYMLINK-FILE include/rte_keepalive.h
  SYMLINK-FILE include/rte_time.h
  SYMLINK-FILE include/rte_rwlock.h
  SYMLINK-FILE include/rte_memcpy.h
  SYMLINK-FILE include/rte_cycles.h
  SYMLINK-FILE include/rte_spinlock.h
  SYMLINK-FILE include/rte_atomic_32.h
  SYMLINK-FILE include/rte_vect.h
  SYMLINK-FILE include/rte_prefetch.h
  SYMLINK-FILE include/rte_byteorder_32.h
  SYMLINK-FILE include/rte_atomic_64.h
  SYMLINK-FILE include/rte_byteorder_64.h
  SYMLINK-FILE include/rte_cpuflags.h
  SYMLINK-FILE include/rte_rtm.h
  SYMLINK-FILE include/rte_atomic.h
  SYMLINK-FILE include/rte_byteorder.h
== Build lib/librte_eal/linuxapp
== Build lib/librte_eal/linuxapp/igb_uio
== Build lib/librte_eal/linuxapp/eal
  CC eal.o
  CC eal_hugepage_info.o
  CC eal_memory.o
  CC eal_thread.o
  CC eal_log.o
  CC eal_pci_vfio.o
  CC eal_debug.o
  CC eal_pci_uio.o
  CC eal_pci.o
  CC eal_alarm.o
  CC eal_common_lcore.o
  CC eal_common_launch.o
  CC eal_common_memzone.o
  CC eal_common_pci.o
  CC eal_lcore.o
  CC eal_pci_vfio_mp_sync.o
  CC eal_common_pci_uio.o
  CC eal_common_timer.o
  CC eal_interrupts.o
  CC eal_timer.o
  CC eal_common_memory.o
  CC eal_common_log.o
  CC eal_common_cpuflags.o
  CC eal_common_errno.o
  CC eal_common_string_fns.o
  CC eal_common_tailqs.o
  CC eal_common_hexdump.o
  CC rte_malloc.o
  SYMLINK-FILE include/exec-env/rte_interrupts.h
  SYMLINK-FILE include/exec-env/rte_dom0_common.h
  SYMLINK-FILE include/exec-env/rte_kni_common.h
  CC malloc_elem.o
  CC eal_common_devargs.o
  CC eal_common_dev.o
  CC eal_common_thread.o
  CC malloc_heap.o
  CC eal_common_options.o
  CC rte_keepalive.o
/work/home/rkwiles/projects/intel/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c: In function \u2018pci_config_extended_tag\u2019:
/work/home/rkwiles/projects/intel/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c:505:2: error: ignoring return value of \u2018fgets\u2019, declared with attribute warn_unused_result [-Werror=unused-result]
  fgets(buf, sizeof(buf), f);
  ^
/work/home/rkwiles/projects/intel/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c: In function \u2018pci_config_max_read_request_size\u2019:
/work/home/rkwiles/projects/intel/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c:545:2: error: ignoring return value of \u2018fgets\u2019, declared with attribute warn_unused_result [-Werror=unused-result]
  fgets(buf, sizeof(buf), f);
  ^
cc1: all warnings being treated as errors
/work/home/rkwiles/projects/intel/dpdk/mk/internal/rte.compile-pre.mk:126: recipe for target 'eal_pci.o' failed
make[7]: *** [eal_pci.o] Error 1
make[7]: *** Waiting for unfinished jobs....
/work/home/rkwiles/projects/intel/dpdk/mk/rte.subdir.mk:61: recipe for target 'eal' failed
make[6]: *** [eal] Error 2
make[6]: *** Waiting for unfinished jobs....
  LD      /work/home/rkwiles/projects/intel/dpdk/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/igb_uio/built-in.o
(cat /dev/null;   echo kernel//work/home/rkwiles/projects/intel/dpdk/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.ko;) > /work/home/rkwiles/projects/intel/dpdk/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/igb_uio/modules.order
  CC [M]  /work/home/rkwiles/projects/intel/dpdk/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /work/home/rkwiles/projects/intel/dpdk/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.mod.o
  LD [M]  /work/home/rkwiles/projects/intel/dpdk/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.ko
INSTALL-MODULE igb_uio.ko
/work/home/rkwiles/projects/intel/dpdk/mk/rte.subdir.mk:61: recipe for target 'linuxapp' failed
make[5]: *** [linuxapp] Error 2
/work/home/rkwiles/projects/intel/dpdk/mk/rte.subdir.mk:61: recipe for target 'librte_eal' failed
make[4]: *** [librte_eal] Error 2
/work/home/rkwiles/projects/intel/dpdk/mk/rte.sdkbuild.mk:77: recipe for target 'lib' failed
make[3]: *** [lib] Error 2
/work/home/rkwiles/projects/intel/dpdk/mk/rte.sdkroot.mk:123: recipe for target 'all' failed
make[2]: *** [all] Error 2
/work/home/rkwiles/projects/intel/dpdk/mk/rte.sdkinstall.mk:84: recipe for target 'pre_install' failed
make[1]: *** [pre_install] Error 2
/work/home/rkwiles/projects/intel/dpdk/mk/rte.sdkroot.mk:98: recipe for target 'install' failed
make: *** [install] Error 2




>If you just want to compile, it is simple:
>	make config T=x86_64-native-linuxapp-gcc O=my-gcc-build
>	make O=my-gcc-build

IMO we have gone backwards in making DPDK easy to build. I agree using ‘make install T=‘ may not be the best solution as ‘install’ implies we are installing the code. I agree not we should not try to build multiple configuration with one command, but we should be able to do ‘make build T=x86_64-native-linuxapp-gcc’ to replace the ‘make install T=‘ command. Now the developer only needs to type one command with to build a configuration and not two. If the developer includes the ‘O=‘ option then the command should create that directory and build the configuration into that directory. For the 80% rule the ‘O=‘ option should not be required.

The ‘make config T= O=‘ then ‘make O=‘ series of commands are not required, even the ‘config’ keyword is not required and just an extra step we do not need. What does the ‘config’ target really add to the made other then creating the ‘build’ directory and a config file. I believe the ‘build’ directory should be dropped/removed all together and just require the ‘T=‘ and/or the ‘O=‘ if they really want to define a different output directory.


>
>Note: the documentation was updated when doing this change.
>If you think something is missing, please comment.
>


Regards,
Keith

Re: [dpdk-dev] Building with 'make install T=' and 'make config T='

[Thomas Monjalon]

2015-12-09 15:32, Wiles, Keith:
> On 12/9/15, 8:59 AM, "Thomas Monjalon" <thomas.monjalon@6wind.com> wrote:
> 
> >2015-12-09 14:39, Wiles, Keith:
> >> I am having a problem with ‘make install T=‘ command as I was using it before. I would normally build a x86_64-native-linuxapp-gcc, clang and icc or a different config all together. Currently the ‘make install T=‘ gives a warning message at the end of the build plus creates the x86_64-native-linuxapp-XXX directory. If I use the suggested ‘make config T=‘ command this command create a directory ‘build’ with a .config file. The problem is this method does not allow me to have multiple builds at the same time.
> >> 
> >> What is the suggested method to have multiple builds without installing  into the local file system?
> >
> >The multiple build is not supported anymore. It was only building with
> >the default configuration.
> >If you want to test various builds, I suggest to use this script:
> >	scripts/test-build.sh
> >	http://dpdk.org/browse/dpdk/commit/?id=cd31ca579c
> 
> Having a build script is great, but it give me an error on building. The script does not have a —help option and the unknown option is not very usefulas it does not explain the two option -jX and -s in that output message. I would have expected a bit more help instructions on using this command and adding a -h or —help would be useful. 

Please check.
There is a -h option.

> The error I get from the following command is: './scripts/test-build.sh x86_64-native-linuxapp-gcc’ building on a Ubuntu 15.10 with all patches. If I use ‘make install T=x86_64-native-linuxapp-gcc’ this command builds correctly with the warning at the end.
[...]
> /work/home/rkwiles/projects/intel/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c: In function \u2018pci_config_extended_tag\u2019:
> /work/home/rkwiles/projects/intel/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c:505:2: error: ignoring return value of \u2018fgets\u2019, declared with attribute warn_unused_result [-Werror=unused-result]
>   fgets(buf, sizeof(buf), f);
>   ^

It is a compilation error, not related to the script.

> >If you just want to compile, it is simple:
> >	make config T=x86_64-native-linuxapp-gcc O=my-gcc-build
> >	make O=my-gcc-build
> 
> IMO we have gone backwards in making DPDK easy to build. I agree using ‘make install T=‘ may not be the best solution as ‘install’ implies we are installing the code. I agree not we should not try to build multiple configuration with one command, but we should be able to do ‘make build T=x86_64-native-linuxapp-gcc’ to replace the ‘make install T=‘ command. Now the developer only needs to type one command with to build a configuration and not two. If the developer includes the ‘O=‘ option then the command should create that directory and build the configuration into that directory. For the 80% rule the ‘O=‘ option should not be required.

The O= option is not required.
The new syntax is closer to the standard behaviour.
You just don't want to type "make config" because you are using a default
configuration.

> The ‘make config T= O=‘ then ‘make O=‘ series of commands are not required, even the ‘config’ keyword is not required and just an extra step we do not need. What does the ‘config’ target really add to the made other then creating the ‘build’ directory and a config file. I believe the ‘build’ directory should be dropped/removed all together and just require the ‘T=‘ and/or the ‘O=‘ if they really want to define a different output directory.

Between "make config" and "make" you can modify the configuration.
In the next release, "make config" will be wrapped by a "configure" script
which will allow to configure your target in one line.
So we will end up with:
	./configure
	make
	make install
It may be weird to you but it is standard to others.

Re: [dpdk-dev] Building with 'make install T=' and 'make config T='

[Wiles, Keith]

On 12/9/15, 10:19 AM, "Thomas Monjalon" <thomas.monjalon@6wind.com> wrote:

>2015-12-09 15:32, Wiles, Keith:
>> On 12/9/15, 8:59 AM, "Thomas Monjalon" <thomas.monjalon@6wind.com> wrote:
>> 
>> >2015-12-09 14:39, Wiles, Keith:
>> >> I am having a problem with ‘make install T=‘ command as I was using it before. I would normally build a x86_64-native-linuxapp-gcc, clang and icc or a different config all together. Currently the ‘make install T=‘ gives a warning message at the end of the build plus creates the x86_64-native-linuxapp-XXX directory. If I use the suggested ‘make config T=‘ command this command create a directory ‘build’ with a .config file. The problem is this method does not allow me to have multiple builds at the same time.
>> >> 
>> >> What is the suggested method to have multiple builds without installing  into the local file system?
>> >
>> >The multiple build is not supported anymore. It was only building with
>> >the default configuration.
>> >If you want to test various builds, I suggest to use this script:
>> >	scripts/test-build.sh
>> >	http://dpdk.org/browse/dpdk/commit/?id=cd31ca579c
>> 
>> Having a build script is great, but it give me an error on building. The script does not have a —help option and the unknown option is not very usefulas it does not explain the two option -jX and -s in that output message. I would have expected a bit more help instructions on using this command and adding a -h or —help would be useful. 
>
>Please check.
>There is a -h option.

The -h option gives the same output as the a unknown option:

rkwiles@rkwiles-supermicro (master):~/.../intel/dpdk$ ./scripts/test-build.sh -h
usage: test-build.sh [-jX] [-s] [config1 [config2] ...]]
rkwiles@rkwiles-supermicro (master):~/.../intel/dpdk$ 


My point was more around the content of the help as it is not very useful as to what the -jX or -s options are, please add more help information as ‘man test-build.sh’ does not work :-)

>
>> The error I get from the following command is: './scripts/test-build.sh x86_64-native-linuxapp-gcc’ building on a Ubuntu 15.10 with all patches. If I use ‘make install T=x86_64-native-linuxapp-gcc’ this command builds correctly with the warning at the end.
>[...]
>> /work/home/rkwiles/projects/intel/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c: In function \u2018pci_config_extended_tag\u2019:
>> /work/home/rkwiles/projects/intel/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c:505:2: error: ignoring return value of \u2018fgets\u2019, declared with attribute warn_unused_result [-Werror=unused-result]
>>   fgets(buf, sizeof(buf), f);
>>   ^
>
>It is a compilation error, not related to the script.

This is strange the ‘make install T=‘ command just works, how do you explain that problem.
The test-build.sh script should be do some setup then ‘make config T= ; make’ so why is this script not working?

The script should work as expected with ‘./scripts/test-build.sh x86_64-native-linuxapp-gcc’ correct?

Could be something wrong with my system, but I doubt it.

>
>> >If you just want to compile, it is simple:
>> >	make config T=x86_64-native-linuxapp-gcc O=my-gcc-build
>> >	make O=my-gcc-build
>> 
>> IMO we have gone backwards in making DPDK easy to build. I agree using ‘make install T=‘ may not be the best solution as ‘install’ implies we are installing the code. I agree not we should not try to build multiple configuration with one command, but we should be able to do ‘make build T=x86_64-native-linuxapp-gcc’ to replace the ‘make install T=‘ command. Now the developer only needs to type one command with to build a configuration and not two. If the developer includes the ‘O=‘ option then the command should create that directory and build the configuration into that directory. For the 80% rule the ‘O=‘ option should not be required.
>
>The O= option is not required.
>The new syntax is closer to the standard behaviour.
>You just don't want to type "make config" because you are using a default
>configuration.

I understand the O= option is not required. I would have liked it to pick the closest configuration to the host system if x86-64 then pick x86_64-native-linuxapp-gcc GCC is the normal default compiler, if a ARM-v7 system then pick the correct configuration or powerpc …
If they want something else then let them use the ’T=‘ option. This would have been a nice to have feature, but not a requirement.

>
>> The ‘make config T= O=‘ then ‘make O=‘ series of commands are not required, even the ‘config’ keyword is not required and just an extra step we do not need. What does the ‘config’ target really add to the made other then creating the ‘build’ directory and a config file. I believe the ‘build’ directory should be dropped/removed all together and just require the ‘T=‘ and/or the ‘O=‘ if they really want to define a different output directory.
>
>Between "make config" and "make" you can modify the configuration.
>In the next release, "make config" will be wrapped by a "configure" script
>which will allow to configure your target in one line.
>So we will end up with:
>	./configure
>	make
>	make install
>It may be weird to you but it is standard to others.

I understand the above configure steps and yes it is nice to have, the only problem is we do not have a real automake-autolib configuration system.

Personally I would not use automake-autolib as it requires more system resources and different version cause different problems plus M4 maybe a great language, but not very friendly. The current DPDK build system just requires make and a shell, which is very common plus very simple to install. If cross-compiling it will be harder to get all of the tools in place to support a real automake system on a embedded environment. Cross-compiling has its own problems to address.

I would like to have the above configure style support, but making the build system a bit more complex is not the answer IMO.

We should never try to build multiple configurations at the same time without using some type of script as the test-build.sh.

Being able to have a very simple build is great and the above steps are great if you have a configure script/build system.

I would like to see done:
 - The ‘build’ directory is nothing special and we should not use ‘build' as a default directory name, but use the configuration name i.e. x86_64-native-linuxapp-gcc or the ‘O=‘ option. Not using ‘build’ this will simplify the places objects are created using a common scheme, we require a configuration name for the build directory always.
 - If we do not attempt to build a default host based configuration then we must require the ’T=‘ option in the below commands I assume a we do not have default.

	$ make config T=… [O=…]      # Just creates the build directory and .config file as it does today. (Possible default build configuration)
	$ make [build] T=… [O=…]     # optional ‘T=‘ option but that would require the build to build all configuration directories which is not desired.
                                     # Just a 'make’ assume ‘make build’
	$ make install [T=…] [O=…]   # installs a possible default or uses the T= configuration. If the configuration directory does not exist then if does a build first.

Using the following we can still have the ./configure above.
	$ ./configure
	$ make [build]
	$ make install       # or just make install without the ‘make’/‘make build'

Sorry, I missed the original emails as I was very busy and then on vacation.

>


Regards,
Keith

Re: [dpdk-dev] Building with 'make install T=' and 'make config T='

[Wiles, Keith]

On 12/9/15, 11:31 AM, "dev on behalf of Wiles, Keith" <dev-bounces@dpdk.org on behalf of keith.wiles@intel.com> wrote:

>On 12/9/15, 10:19 AM, "Thomas Monjalon" <thomas.monjalon@6wind.com> wrote:

BTW, I am not overly concerned about the build system per say I just wish I had put my $0.02 worth in before the change. We can leave as it is now.

The test-build.sh script build does appear to be a real problem. I would like to understand why it does not work. Adding a better help message should be an easy fix for someone that wrote the script or I can make the changes, just let me know.

>
>>2015-12-09 15:32, Wiles, Keith:
>>> On 12/9/15, 8:59 AM, "Thomas Monjalon" <thomas.monjalon@6wind.com> wrote:
>>> 
>>> >2015-12-09 14:39, Wiles, Keith:
>>> >> I am having a problem with ‘make install T=‘ command as I was using it before. I would normally build a x86_64-native-linuxapp-gcc, clang and icc or a different config all together. Currently the ‘make install T=‘ gives a warning message at the end of the build plus creates the x86_64-native-linuxapp-XXX directory. If I use the suggested ‘make config T=‘ command this command create a directory ‘build’ with a .config file. The problem is this method does not allow me to have multiple builds at the same time.
>>> >> 
>>> >> What is the suggested method to have multiple builds without installing  into the local file system?
>>> >
>>> >The multiple build is not supported anymore. It was only building with
>>> >the default configuration.
>>> >If you want to test various builds, I suggest to use this script:
>>> >	scripts/test-build.sh
>>> >	http://dpdk.org/browse/dpdk/commit/?id=cd31ca579c
>>> 
>>> Having a build script is great, but it give me an error on building. The script does not have a —help option and the unknown option is not very usefulas it does not explain the two option -jX and -s in that output message. I would have expected a bit more help instructions on using this command and adding a -h or —help would be useful. 
>>
>>Please check.
>>There is a -h option.
>
>The -h option gives the same output as the a unknown option:
>
>rkwiles@rkwiles-supermicro (master):~/.../intel/dpdk$ ./scripts/test-build.sh -h
>usage: test-build.sh [-jX] [-s] [config1 [config2] ...]]
>rkwiles@rkwiles-supermicro (master):~/.../intel/dpdk$ 
>
>
>My point was more around the content of the help as it is not very useful as to what the -jX or -s options are, please add more help information as ‘man test-build.sh’ does not work :-)
>
>>
>>> The error I get from the following command is: './scripts/test-build.sh x86_64-native-linuxapp-gcc’ building on a Ubuntu 15.10 with all patches. If I use ‘make install T=x86_64-native-linuxapp-gcc’ this command builds correctly with the warning at the end.
>>[...]
>>> /work/home/rkwiles/projects/intel/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c: In function \u2018pci_config_extended_tag\u2019:
>>> /work/home/rkwiles/projects/intel/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c:505:2: error: ignoring return value of \u2018fgets\u2019, declared with attribute warn_unused_result [-Werror=unused-result]
>>>   fgets(buf, sizeof(buf), f);
>>>   ^
>>
>>It is a compilation error, not related to the script.
>
>This is strange the ‘make install T=‘ command just works, how do you explain that problem.
>The test-build.sh script should be do some setup then ‘make config T= ; make’ so why is this script not working?
>
>The script should work as expected with ‘./scripts/test-build.sh x86_64-native-linuxapp-gcc’ correct?
>
>Could be something wrong with my system, but I doubt it.
>
>>
>>> >If you just want to compile, it is simple:
>>> >	make config T=x86_64-native-linuxapp-gcc O=my-gcc-build
>>> >	make O=my-gcc-build
>>> 
>>> IMO we have gone backwards in making DPDK easy to build. I agree using ‘make install T=‘ may not be the best solution as ‘install’ implies we are installing the code. I agree not we should not try to build multiple configuration with one command, but we should be able to do ‘make build T=x86_64-native-linuxapp-gcc’ to replace the ‘make install T=‘ command. Now the developer only needs to type one command with to build a configuration and not two. If the developer includes the ‘O=‘ option then the command should create that directory and build the configuration into that directory. For the 80% rule the ‘O=‘ option should not be required.
>>
>>The O= option is not required.
>>The new syntax is closer to the standard behaviour.
>>You just don't want to type "make config" because you are using a default
>>configuration.
>
>I understand the O= option is not required. I would have liked it to pick the closest configuration to the host system if x86-64 then pick x86_64-native-linuxapp-gcc GCC is the normal default compiler, if a ARM-v7 system then pick the correct configuration or powerpc …
>If they want something else then let them use the ’T=‘ option. This would have been a nice to have feature, but not a requirement.
>
>>
>>> The ‘make config T= O=‘ then ‘make O=‘ series of commands are not required, even the ‘config’ keyword is not required and just an extra step we do not need. What does the ‘config’ target really add to the made other then creating the ‘build’ directory and a config file. I believe the ‘build’ directory should be dropped/removed all together and just require the ‘T=‘ and/or the ‘O=‘ if they really want to define a different output directory.
>>
>>Between "make config" and "make" you can modify the configuration.
>>In the next release, "make config" will be wrapped by a "configure" script
>>which will allow to configure your target in one line.
>>So we will end up with:
>>	./configure
>>	make
>>	make install
>>It may be weird to you but it is standard to others.
>
>I understand the above configure steps and yes it is nice to have, the only problem is we do not have a real automake-autolib configuration system.
>
>Personally I would not use automake-autolib as it requires more system resources and different version cause different problems plus M4 maybe a great language, but not very friendly. The current DPDK build system just requires make and a shell, which is very common plus very simple to install. If cross-compiling it will be harder to get all of the tools in place to support a real automake system on a embedded environment. Cross-compiling has its own problems to address.
>
>I would like to have the above configure style support, but making the build system a bit more complex is not the answer IMO.
>
>We should never try to build multiple configurations at the same time without using some type of script as the test-build.sh.
>
>Being able to have a very simple build is great and the above steps are great if you have a configure script/build system.
>
>I would like to see done:
> - The ‘build’ directory is nothing special and we should not use ‘build' as a default directory name, but use the configuration name i.e. x86_64-native-linuxapp-gcc or the ‘O=‘ option. Not using ‘build’ this will simplify the places objects are created using a common scheme, we require a configuration name for the build directory always.
> - If we do not attempt to build a default host based configuration then we must require the ’T=‘ option in the below commands I assume a we do not have default.
>
>	$ make config T=… [O=…]      # Just creates the build directory and .config file as it does today. (Possible default build configuration)
>	$ make [build] T=… [O=…]     # optional ‘T=‘ option but that would require the build to build all configuration directories which is not desired.
>                                     # Just a 'make’ assume ‘make build’
>	$ make install [T=…] [O=…]   # installs a possible default or uses the T= configuration. If the configuration directory does not exist then if does a build first.
>
>Using the following we can still have the ./configure above.
>	$ ./configure
>	$ make [build]
>	$ make install       # or just make install without the ‘make’/‘make build'
>
>Sorry, I missed the original emails as I was very busy and then on vacation.
>
>>
>
>
>Regards,
>Keith
>
>
>
>
>


Regards,
Keith

Re: [dpdk-dev] Building with 'make install T=' and 'make config T='

[Thomas Monjalon]

2015-12-09 17:44, Wiles, Keith:
> On 12/9/15, 11:31 AM, "dev on behalf of Wiles, Keith" <dev-bounces@dpdk.org on behalf of keith.wiles@intel.com> wrote:
> 
> >On 12/9/15, 10:19 AM, "Thomas Monjalon" <thomas.monjalon@6wind.com> wrote:
> 
> BTW, I am not overly concerned about the build system per say I just wish I had put my $0.02 worth in before the change. We can leave as it is now.
> 
> The test-build.sh script build does appear to be a real problem. I would like to understand why it does not work.

No your compilation error is a real problem.
The script enables some options which probably trigger the problem.
It is a script to test some compilation options.
Please check before doing some wrong assumptions. You are burning my time.

> Adding a better help message should be an easy fix for someone that wrote the script or I can make the changes, just let me know.

I will improve the help message.

Re: [dpdk-dev] Building with 'make install T=' and 'make config T='

[Thomas Monjalon]

2015-12-09 17:31, Wiles, Keith:
> On 12/9/15, 10:19 AM, "Thomas Monjalon" <thomas.monjalon@6wind.com> wrote:
> >Between "make config" and "make" you can modify the configuration.
> >In the next release, "make config" will be wrapped by a "configure" script
> >which will allow to configure your target in one line.
> >So we will end up with:
> >	./configure
> >	make
> >	make install
> >It may be weird to you but it is standard to others.
> 
> I understand the above configure steps and yes it is nice to have, the only problem is we do not have a real automake-autolib configuration system.
> 
> Personally I would not use automake-autolib as it requires more system resources and different version cause different problems plus M4 maybe a great language, but not very friendly. The current DPDK build system just requires make and a shell, which is very common plus very simple to install. If cross-compiling it will be harder to get all of the tools in place to support a real automake system on a embedded environment. Cross-compiling has its own problems to address.

I said "make config" will be wrapped by a "configure" script.
Does it sound like using autotools? No

[dpdk-dev] [PATCH] scripts: add help for build testing

[Thomas Monjalon]

Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
---
 scripts/test-build.sh | 22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/scripts/test-build.sh b/scripts/test-build.sh
index 6e67c8f..a9075af 100755
--- a/scripts/test-build.sh
+++ b/scripts/test-build.sh
@@ -40,7 +40,25 @@
 . scripts/load-devel-config.sh
 
 print_usage () {
-	echo "usage: $(basename $0) [-jX] [-s] [config1 [config2] ...]]"
+	echo "usage: $(basename $0) [-h] [-jX] [-s] [config1 [config2] ...]]"
+}
+
+print_help () {
+	echo 'Test building several targets with different options'
+	echo
+	print_usage
+	cat <<- END_OF_HELP
+
+	options:
+	       -h   this help
+	       -jX  use X parallel jobs in "make"
+	       -s   short test with only first config without examples/doc
+
+	config:
+	       default config name + config switches delimited with "+" sign
+	       example: x86_64-native-linuxapp-gcc+next+shared+combined
+	       external dependencies defined with DPDK_DEP_* variables
+	END_OF_HELP
 }
 
 J=$DPDK_MAKE_JOBS
@@ -49,7 +67,7 @@ while getopts hj:s ARG ; do
 	case $ARG in
 		j ) J=$OPTARG ;;
 		s ) short=true ;;
-		h ) print_usage ; exit 0 ;;
+		h ) print_help ; exit 0 ;;
 		? ) print_usage ; exit 1 ;;
 	esac
 done
-- 
2.5.2

Re: [dpdk-dev] [PATCH] scripts: add help for build testing

[Thomas Monjalon]

2015-12-13 03:03, Thomas Monjalon:
> Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>

Applied