On 12/9/15, 10:19 AM, "Thomas Monjalon" <thomas.monjalon at 6wind.com> wrote:
>2015-12-09 15:32, Wiles, Keith: >> On 12/9/15, 8:59 AM, "Thomas Monjalon" <thomas.monjalon at 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 at rkwiles-supermicro (master):~/.../intel/dpdk$ ./scripts/test-build.sh -h usage: test-build.sh [-jX] [-s] [config1 [config2] ...]] rkwiles at 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
